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DETAILED ACTION 
Claim Objections 

1 . Claims 11, 1 3, 26, 29 are objected to because of the following informalities: 

a) In claim 1 1 line 1, "claim 1" should be changed to -claim 4-. 

b) In claim 13 line 1, "claim 1" should be changed to -claim 12-. 

c) In claim 26 line 10, "congestion bit error" should be deleted. 

d) In claim 29 line 1 , "claim 27" should be changed to -claim 28-. 
Appropriate correction is required. 

Claim Rejections - 35 USC § 103 

2. The following is a quotation of 35 U.S.C. 1 03(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 1 02 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary sl<ill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

3. Claims 1-3, 12-14, 19-21 and 26-29 are rejected under 35 U.S.C. 103(a) as 
being unpatentable over U.S. Patent No. 6,922,390 to Chapman et al in view of U.S. 
Patent No. 6,587,437 to Lee et al. 

Referring to claim 1 , Chapman et al disclose in Figures 1 and 2 a method for 
providing a transport protocol within a network, comprising: 

Receiving (at intermediate nodes) multiple packets (control packets), wherein 
each of the received packets includes a header and an associated sequence number 
(control sequence number), wherein the header includes an impending congestion 
indication (congestion stamp in congestion notification field). The nodes can detect and 
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foresee congestion (impending congestion) in the future. Refer to Column 3, lines 25- 
36; Column 4, line 61 to Column 5, line 2; and Column 6, lines 12-39. 

Monitoring the network for congestion caused by the received packets. Sender 
104 sends packets with the congestion notification field set to "not congested"; an 
intermediate node on the path followed by the control packet can apply a congestion 
stamp to the control packet by setting the bits in the congestion notification field to 
"congested" to forecast congestion. Refer to Column 5, lines 12-32. 

Marking (using congestion stamp) the header (congestion notification field) of 
some of the packets with an impending congestion indication based on the outcome of 
the monitoring. Refer to Column 5, lines 12-32. 

Transmitting the monitored multiple packets through the network (from sender 
1 04 to receiver 1 1 2). Refer to Column 4, lines 56-61 . 

Returning (from receiver 112) acknowledgements of receipt (outgoing control 
packets) for each of the transmitted packets, based on the sequence number (control 
sequence number) associated with each of the packets, and any associated marked 
impending congestion indication (congestion stamp in congestion notification field). 
Receiver 112 checks for control packets with congestion stamps and returns an 
outgoing control packet as an acknowledgement to sender 104. Refer to Column 5, 
lines 33-47. 

Monitoring (at sender 104) each of the received acknowledgements (outgoing 
control packets) for the sequence number (control sequence number) and the marked 
impending congestion indication (congestion stamp in congestion notification field) 
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associated with each of the received packets. Sender 104 receives the outgoing control 
pacl^ets from receiver 1 12, so that it is notified that congestion exists or is developing in 
the network. Refer to Column 5, lines 48-64. 

Invoking a congestion control mechanism (adjustment of TCP-like adaptive 
window) to control a congestion window size which regulates the transmitted packets 
based on the monitoring of the acknowledgements (outgoing control packets) and the 
marked impending congestion indication. Sender 104 adjusts its TCP-like adaptive 
window to control its data-sending rate according to the forecasted congestion. Refer to 
Column 3, line 65 to Column 4, line 30 and Column 6, lines 13-24. 

Chapman et al do not disclose that the header includes a congestion alleviation 
indication and that after invoking a congestion control mechanism, further marking the 
header with a congestion alleviation indication. 

Lee et al disclose a congestion control mechanism in which each network 
element can inform other network elements of congestion by setting the Explicit 
Fonward Congestion Indicator (EFCI) bit in the header of each data cell. A network 
element in an impending congested state or in a currently congested state may set the 
EFCI bit. A network element that is not in a congested state or an impending congested 
state will not modify the value of the EFCI indication. If the EFCI bit is set, the system 
will lower its cell rate to control congestion. Once the congestion is alleviated, the EFCI 
bit will be set back to "0" to indicate that the network element is not in a congested state 
or will not be in a congested state. Refer to Column 2, lines 25-41 and Column 3, line 
51 to Column 4, line 10. Therefore, it would have been obvious to one of ordinary skill 
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in the art at the time the invention was made to include that the header includes a 
congestion alleviation indication and that after invoking a congestion control 
mechanism, further marking the header with a congestion alleviation indication. One 
would be motivated to do so in order to indicate to the network elements when the 
network is cleared of congestion, so that no more measures will be taken to reduce 
congestion. 

Referring to claims 2, 1 3, 20, 27 and 28, Chapman et al disclose that the method 
further comprises: 

Monitoring (Figure 4, steps 400, 402, 404, 406 and 408) the number of packets 
waiting in line (Figure 2, buffer 210) to be transmitted. Refer to Column 3, lines 36-57 
and Column 7, lines 1-54. 

Comparing (Figure 4, step 410) the number of packets waiting in line to a 
predetermined minimum line size (Figure 5, MINth) and a predetermined maximum line 
size (Figure 5, MAXth). If the virtual buffer fills above the threshold level, the sender 
invokes the congestion notification by marking an outgoing control packet with a 
congestion stamp. Refer to Column 7, 33-54. Furthennore, as shown in Figure 5, "the 
100% fill of virtual buffer 210 is equated to the maximum threshold of RED (MAXth), 
while the minimum threshold (MINth) is calculated by subtracting the projected local 
requirement from MAXth...". Refer to Column 7, lines 55-67. 

Referring to claims 3, 14, 21 and 29, Chapman et al disclose that marking the 
header of some of the packets with an impending congestion indication comprises: 
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If the number of packets waiting in line (Figure 2, virtual buffer 210) is greater 
than the predetermined minimum line size (Figure 5b, MINth) and less than the 
predetermined maximum line size (Figure 5b, MAXth), then marking (Figure 4, step 
410) the header of some of the received packets based on a predicted determined 
probability (to increase the congestion marking probability) with an impending 
congestion indication (congestion stamp in congestion notification field). In Figure 5b, 
the system is considered to be congested if the current fill is between the MINth and 
MAXth. Refer to Column 7, lines 55-67. 

Chapman et al do not disclose that if the number of packets waiting in line is 
greater than the predetermined maximum line size, then the packets waiting in line 
beyond the predetermined maximum line size will be dropped. 

However, Chapman et al disclose that in a standard routed network, 
"implementing congestion control involves the monitoring of the average buffer fill such 
that discard may be effected before the buffer overflows" (Column 1, lines 41-44). 
Therefore, it would have been obvious to one of ordinary skill in the art at the time the 
invention was made to include that if the number of packets waiting in line is greater 
than the predetermined maximum line size, then the packets waiting in line beyond the 
predetermined maximum line size will be dropped; the motivation being in order to 
prevent the buffer from overflowing. 

Referring to claim 12, refer to the rejection of claim 1 . Furthermore, as shown in 
Figure 2, "the congestion control mechanism is implemented by software executed by 
the processor 206" (Column 3, lines 11-13). 
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Referring to claim 19, refer to the rejection of claim 1 . Furthermore, as shown in 
Figure 2, the system comprises a storage device (buffers), an output device (output to 
ring 102), and a processor (processor 206) programmed to repeatedly perform the 
method of claim 1 . Refer to Column 2, lines 47-55 and Column 3, lines 1-17 and lines 
37-48. 

Referring to claim 26, refer to the rejection of claim 1 . Chapman et al do not 
specifically disclose that the method can be performed by sender and receiver base 
stations. However, the method can be implemented in wired or wireless environments, 
4. Claims 8 and 33 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
U.S. Patent No. 6.922,390 to Chapman et al in view of U.S. Patent No. 6,587,437 to 
Lee et al, and in further view of U.S. Patent No. 6,947,446 to LaGalbo et al. 

Chapman et al do not disclose providing a forward error correction to the header 
of each packet. 

LoGalbo et al disclose in Figure 6 a link layer header 310 with a forward error 
correction (FEC) field 622 that is used to indicate what kind of error correcting code was 
used to encode the data block 210 corresponding to the link layer header 310. Refer to 
Column 9, line 60 to Column 10, line 8 and Column 10, line 65 to Column 11, line 24. 
Therefore, it would have been obvious to one of ordinary skill in the art at the time the 
invention was made to include providing a forward error correction to the header of each 
packet. One would be motivated to do so in order to provide information about the error 
correcting code used for the data block in the header, so that the transmitting and 
receiving side will be able to detect errors using information from the packet header. 
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5. Claims 9, 10 and 34-36 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over U.S. Patent No. 6,922,390 to Chapman et al in view of U.S. Patent 
No. 6,587,437 to Lee et al, and in further view of U.S. Patent No. 6,937,600 to Takagi. 

Referring to claims 9, 34 and 35, Chapman et al do not disclose that marking the 
header of some of the multiple packets with an impending congestion indication 
comprises: flagging CE (Congestion Experienced) bits in the header of some of the 
multiple packets and flagging a CWR (Congestion Window Reduced) bit in the header 
of some of the multiple packets. 

Takagi et al disclose in Figure 7 that the seventh bit of the Type Of Service field 
in the IP header is set as a CE (Congestion Experienced) field and in Figure 8 that the 
eighth bit of the Reserved field in the IP header is set as a CWR (Congestion Window 
Reduced) bit. Both bits are used for congestion control. The CE bit is set to "1" when 
the average queue length exceeds a threshold and the CWR bit is set to "1" to indicate 
that the window size is reduced to control congestion. Refer to Column 13, line 30 to 
Column 14, line 36. Therefore, it would have been obvious to one of ordinary skill in the 
art at the time the invention was made to include that marking the header of some of the 
multiple packets with an impending congestion indication comprises: flagging CE 
(Congestion Experienced) bits in the header of some of the multiple packets and 
flagging a CWR (Congestion Window Reduced) bit in the header of some of the multiple 
packets. One would be motivated to do so in order to notify the transmitter or receiver 
side that the system is congested (CE) and that the window is being reduced to control 
the congestion (CWR) , thereby facilitating data transmission. 
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Referring to claims 10 and 36, Chapman et al do not disclose that returning 
acknowledgements comprise flagging an ECE (Explicit Congestion Notification Echo) bit 
in the acknowledgements. 

Takagi discloses in Figure 8 that the ninth bit of the Reserved field in the TCP 
header is set as an ECN-echo bit. When the reception side receives a TCP/IP packet 
with the CE bit set to "1", it transmits a TCP ACK packet with the ECN-echo bit set to 
"1". When the transmission terminal receives the TCP ACK with the ECN-echo bit set 
to "1", it reduces its window size to control congestion. Refer to Column 13, line 30 to 
Column 14, line 36. Therefore, it would have been obvious to one of ordinary skill in the 
art at the time the invention was made to include that returning acknowledgements 
comprise flagging an ECE (Explicit Congestion Notification Echo) bit in the 
acknowledgements. One would be motivated to do so in order to notify the 
transmission terminal that the reception terminal is aware of the congestion and the 
transmission terminal will begin window reduction accordingly. 

Allowable Subject Matter 
6. Claims 4-7, 15-18, 22-25 and 30-32 are objected to as being dependent upon a 
rejected base claim, but would be allowable if rewritten in independent form including all 
of the limitations of the base claim and any intervening claims. 
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Conclusion 



7. Any inquiry concerning this communication or earlier communications from tlie 
examiner should be directed to Christine Ng whose telephone number is (571) 272- 
3124. The examiner can normally be reached on M-F; 8:00 am - 5:00 pm. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Ricky Ngo can be reached on (571) 272-3139. The fax phone number for 
the organization where this application or proceeding is assigned is 571-273-8300. 

Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). 



C. Ng ^ 
January 31 , 2006 
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